Follow on to Discord thread: https://discord.com/channels/1358869848138059966/1516855742060171435/1518374972597207243

What & why

Adds appeals@modelcontextprotocol.io as an email Google Group so that banned or external users have an out-of-band channel to appeal Code of Conduct actions. When someone is blocked at the GitHub org level they lose access to all repos/issues/PRs, so the appeals channel must be email — it cannot live in GitHub.

This encourages moderators to not dwell too long on handing out bans for suspected spam or AI slop, because it makes potentially incorrect decisions reversible. Prior to this change, there is no official channel for an incorrectly-banned person to invest in presenting a case for why reinstatement should be considered.

After this inbox is confirmed working, we can add it in a section in the Code of Conduct and provide guidelines for how to submit an appeal.

This change technically mirrors the existing antitrust@ / catch-all@ email-group setup: an isEmailGroup: true group with no new GoogleConfig fields, and an explicitly curated member list (exactly like the hand-listed antitrust@ members at the bottom of users.ts).

Behavior this unblocks

• Anyone can email in — including external/banned users. The existing isEmailGroup branch in google.ts already sets whoCanPostMessage: ANYONE_CAN_POST, so no google.ts change is needed.
• Delivers to the current moderation + lead-maintainer team — ROLE_IDS.APPEALS is added to a curated set of 8 member entries (see below).
• Message archive is restricted to group members — for isEmailGroup groups, google.ts sets whoCanViewGroup: 'ALL_MEMBERS_CAN_VIEW'. Only the group's members can read the appeal threads.

Curated membership

ROLE_IDS.APPEALS is added to these 8 users.ts entries:

⚠️ jonathanhefner and pederhp have no managed @modelcontextprotocol.io mailbox and no personal email: in users.ts, so google.ts (if (!memberEmail) return) produces no group membership for them — they will not receive appeals mail until they're provisioned a mailbox or a personal email: is added. APPEALS is on their entries so they auto-join the moment they get an address. The other 6 entries resolve to live mailboxes: cliff@, david@, den@, ola@, shaun.smith@, tadas@.

We can provision their inboxes in a follow up if needed, though I figure we'd discuss any appeals in Discord anyway, so not critical.

The change — three files

1. src/config/roleIds.ts — add APPEALS: 'appeals' to ROLE_IDS (the RoleId union derives from this, so no other type edits needed).
2. src/config/roles.ts — add an isEmailGroup role { id: ROLE_IDS.APPEALS, description: 'Code of Conduct ban appeals inbox', google: { group: 'appeals', isEmailGroup: true } }, alongside ANTITRUST / CATCH_ALL.
3. src/config/users.ts — append ROLE_IDS.APPEALS to the 8 curated entries above.

Scope kept intentionally minimal

• No changes to google.ts — the existing isEmailGroup branch and membership loop already produce everything needed.
• No new GoogleConfig fields.
• No changes to anyone's base MODERATORS/LEAD_MAINTAINERS/CORE_MAINTAINERS roles — appeals membership is curated independently, so this PR does not touch unrelated group/GitHub-team memberships.

Verification

• npm run check (format:check + validate + test) passes: Prettier clean, config validation green (role references + member ordering), 23/23 config tests pass.
• google.ts is unchanged — git diff main --name-only shows only src/config/roleIds.ts, src/config/roles.ts, src/config/users.ts.
• Exactly 8 users.ts entries gained ROLE_IDS.APPEALS: dsp-ant, localden, tadasant, olaservo, evalstate, cliffhall, jonathanhefner, pederhp. Justin (jspahrsummers, emeritus), Paul (pcarleton), and bhosmer-ant are intentionally not members.
• Resolved deliverable mailboxes (via google.ts email resolution): 6 — cliff@, david@, den@, ola@, shaun.smith@, tadas@. jonathanhefner / pederhp resolve to none (flagged above).
• npx tsc on the config files is clean. The full npm run build reports one pre-existing, unrelated error — Cannot find module '@pulumi/googleworkspace' in google.ts — because the generated Pulumi SDK under sdks/googleworkspace isn't built in a non-deploy checkout; it reproduces on a clean main.